In a typical communications network a wireless device, communicates via a RAN to one or more CNs. The communications network may also be referred to as e.g. a wireless communications network, a wireless communications system, a communications network, a communications system, a network or a system.
The wireless device may be a device by which a subscriber may access services offered by an operator's network and services outside operator's network to which the operator's RAN and CN provide access, e.g. access to the Internet. The wireless device may be any device, mobile or stationary, enabled to communicate over a radio channel in the communications network, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Device to Device (D2D) device, Internet of Things (IoT) device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The wireless device may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another wireless device or a server.
The RAN covers a geographical area which is divided into cell areas, with each cell area being served by a RAN node. The RAN node may be called a base station such as a Radio Base Station (RBS), evolved NodeB (eNB), NodeB, B node, Radio Network Controller (RNC), Base Station Controller (BSC), Base Transceiver Station (BTS), depending on the technology and terminology used. A cell is a geographical area where radio coverage is provided by the RAN node at a RAN node site. The RAN node communicates with the wireless device(s) within range of the RAN node.
According to the Third Generation Partnership Project (3GPP), Multimedia Broadcast Multicast Services (MBMS) “is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients. Transmitting the same data to multiple recipients allows network resources to be shared.” MBMS offers two modes: broadcast mode and multicast mode. The MBMS architecture enables the efficient usage of radio network and core network resources. evolved MBMS (eMBMS) may be described as the Long Term Evolution (LTE) version of MBMS. The eMBMS evolution brings improved performance thanks to higher and more flexible LTE bit rates, single frequency network operations, and carrier configuration flexibility.
In MBMS, there are some network nodes or functional entities which are important. Multi-cell/multicast Coordination Entity (MCE) is a network node or functional entity which is responsible for allocation of time and frequency resources for MBMS transmission. The MCE may be co-located with for example an eNB. Another network node is the MBMS-GateWay (MBMS-GW), which is the entry point for incoming broadcast/multicast data traffic. The MBMS-GW broadcasts data packets to all eNBs within an area. Broadcast Multicast-Service Centre (BM-SC) is a network node or functional entity which is necessary in order for a communications network to support MBMS. The BM-SC is in charge of providing service to the end user.
Some of the reference points in MBMS are Sn, SGmb and Sm. Sn is the reference point for the control plane between the MBMS-GW and a Serving General packet radio service Support Node (SGSN). SGmb is the reference point for the control plane between BM-SC and the MBMS-GW. Sm is the reference point for the control plane between the Mobility Management Entity (MME) and the MBMS-GW. M3 Application Protocol (M3AP) supports the M3 interface which is between the MCE and the MBMS-GW. A reference point may also be referred to as an interface. Signaling between nodes is exchanged at a reference point.
The purpose of a MBMS Session Start procedure is to request the RAN to notify wireless devices about an upcoming MBMS Session of a given MBMS Bearer Service and to establish a MBMS Radio Access Bearer (RAB) and MBMS signalling connection for this MBMS Session. The MBMS Session Start procedure is triggered by the CN. For example, the CN initiates the procedure by sending a MBMS Session Start request message to the RNC. The MBMS Session Start request message comprises different parameters. The RNC acts according to the received MBMS Session Start request message. The RNC sends a MBMS Session Start response message or a MBMS Session Start failure message to the core network, depending on the outcome of the procedure.
According to 3GPP, data stored in location registers are automatically updated in normal operation. The main information stored in a location register defines the location of each wireless device and the subscriber data required to handle traffic for each mobile subscriber. The loss or corruption of these data will seriously degrade the service offered to wireless device subscribers. It is therefore necessary to define procedures to limit the effects of failure of a location register, and to restore the location register data automatically. Such restoration procedures are related to failure and/or restart of several types of network nodes and network paths/interfaces, such as e.g. MBMS-GW, MME, SGSN etc.
A failure may be a failure to receive a particular message, failure of a hardware or software component of a network node. A failure may be full/complete or partial. After a node has been restarted, all its bearer contexts are deleted.
3GPP has started a project called eMBMS restoration procedures, where the objective of is to specify enhanced restoration procedures to explicitly define the Evolved Packet System (EPS) behavior and enable restoration of the eMBMS service when possible in order to minimize the end-user service impact upon different kinds of failure scenarios as follows:                MBMS-GW failure/restart        MME/SGSN failure/restart        MCE failure/restart        BM-SC failure/restart        Sm/Sn path failure        M3AP path failure        SGmb path failure        
The project will also study and possibly define restoration procedures for the following scenarios:                M1 path failure        SGi-mb path failure        
So far, Sm path failure/M3AP path failure/MME and SGSN failure/MBMS-GW restart have been discussed and agreed. The rest failure scenarios will be addressed at the coming 3GPP meetings.
Today, there is no time adjustment in the standard and MME implementation, because an Absolute start time (Information Element (IE) “Time of MBMS Data Transfer”) is usually used, which in fact requires no adjustment. However, the absolute start time is optional, without it, the adjustment is needed.
According to 3GPP TS 25.413, V.11.3.0, the RNC will reject a MBMS session start message received from another SGSN if the same MBMS services have been established via an existing SGSN. This makes the restoration for Sn failure impossible.
In the current standard, when both a relative start time (IE “Minimum Time to MBMS Data Transfer”) and an absolute start time (IE “Time of MBMS Data Transfer”) exist in the message, the problem described above will happen.
Moreover, the standard requires, during restoration procedure, that the MME shall send the un-adjusted parameters. Thus, it is not possible to have an adjustment too even without an absolute start time.
SGSN Failure or Sn Path Failure
In eMBMS, during a Sn path failure and in order to re-establish an eMBMS session, the MBMS-GW may select another SGSN and send an MBMS Session Start request message for an MBMS service which was controlled by the old SGSN, where the path between the old SGSN and the MBMS-GW has failed. Subsequently, the new SGSN sends a MBMS session start request to the RNC. But there is an issue according to the existing requirement described in section 8.36.4 in 3GPP TS 25.413, V.11.3.0:
“8.36.4 Abnormal Conditions
    If, for a MBMS RAB requested to be set up, the PDP Type Information IE and/or PDP Type Information extension IE is not present, the RNC shall continue with the procedure.    If an MBMS SESSION START message from a given CN Node provides a TMGI IE that is used for an already established and running MBMS Session provided by the same CN Node, and the indicated MBMS Service Area IE refers to an MBMS Service Area that is partially or completely overlapping with the MBMS Service Area of the already established and running MBMS Session, then the RNC shall return an MBMS SESSION START FAILURE message with the cause value “TMGI in Use and overlapping MBMS Service Area”.    If an MBMS SESSION START message from a given CN Node provides a TMGI IE that is used for an already established and running MBMS Session provided by another CN Node, and the indicated MBMS Service Area IE refers to a different MBMS Service Area that is partially overlapping with the MBMS Service Area of the already established and running MBMS Session, then the RNC shall return an MBMS SESSION START FAILURE message with the cause value “TMGI in Use and overlapping MBMS Service Area”.”
PDP mentioned above is short for Packet Data Protocol. TMGI is a parameter that may be comprised in the MBMS Session Start request message and is short for Temporary Mobile Group Identity. The TMGI uniquely identifies the MBMS Bearer Service.
So, some enhancements are required.
MME Failure/Sm Path Failure or MBMS-GW Failure/SGmb Failure
In eMBMS, if a MBMS-GW failure or a SGmb path failure happens, the BM-SC may select a new MBMS-GW to re-establish the session. Thus, the new MBMS-GW should setup the session with old MME for the ongoing session by sending a MBMS Start Session Request comprising the same TMGI. In the SGmb failure case, since the old MME still keeps a General packet radio service Tunneling Protocol (GTP) session with the old MBMS-GW, when the BM-SC and new MBMS-GW sends a MBMS Start Session Request, it should notify the MME that this Start message is for restoration, otherwise, the MME may discard it. Similarly, if a MME failure or Sm path failure happens, the MBMS-GW may select a new MME to re-establish the control plane. Thus the new MME should setup the control plane with old MCE for the ongoing session by sending a MBMS Start Session Request with the same TMGI. FIG. 1 describes this scenario and involves a MBMS-GW 10, an old MME 13, a new MME 15 and a MCE 18. The scenario comprises the following steps:
Step 101
The MBMS-GW 10 sends a MBMS Session Start request message to the old MME 13.
Step 102
A communication failure between the old MME 13 and the MBMS-GW 10 is detected by the MBMS-GW 10.
Step 103
The MBMS-GW 10 sends a MBMS Session start request message to the new MME 15.
Step 104
The new MME 15 sends a MBMS Session Start request message to the MCE 18.
Note that the old MME 13 and the new MME 15 in FIG. 1 may be the same MME.
However, in the Sm failure case, since the MCE 18 still keeps the old M3AP association with the old MME 13, when the new MME 15 sends a MBMS Start Session Request, it should notify the MCE 18 this Start message is for restoration, otherwise, the MCE 18 may discard it. Currently in the standard, i.e. 3GPP TS 23.007, V.12.0.0, in this failure situation, it is required that the MME should keep all parameters unchanged when it sends a MBMS Start Session Request to the MCE 18. This means that when the MBMS-GW 10 re-establishes the session to the new MME 11, it will comprise the unchanged parameters, such as e.g. “MBMS Session Duration” and “MBMS Time to Data Transfer”. Those parameters should be adjusted. Otherwise, the new MME 11 will meet the problem as below with these unchanged parameters.
Note that there are many use cases where no explicit MBMS Stop message is sent to the MME to save the network signaling, by skipping the explicit MBMS session stop request message, the downstream nodes, e.g. MME/SGSN/MCE/RNC may locally delete resources for the eMBMS service once the duration is expired. So incorrect duration will lead to extra resource allocated in the MME/SGSN and the MCE/RNC for an implicitly stopped eMBMS session.
For example, if a duration time=2 hours and that the session was started at 1 o'clock. At 2 o'clock restoration happens. Then, the duration time should be 1 hour. Without an adjustment, the new MME receives a session with duration still 2 hours. If the MME misses the MBMS Stop Session Request from the MBMS-GW due to a Sm link failure, the session will be hanging for 1 more hour, in which period the session with the same TMGI cannot be re-started. This may be because the MME may only remove that session after duration time expires. The same problem exists for MCE
It is also the same problem for the SGSN when a new SGSN has been selected to re-establish the eMBMS session control path by the MBMS-GW. In such case, the MBMS-GW may use the adjusted duration instead.